Codecov Report

❌ Patch coverage is 93.89313% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.03%. Comparing base (947226b) to head (1f90e7e).

@@            Coverage Diff             @@
##           master     #148      +/-   ##
==========================================
+ Coverage   89.69%   90.03%   +0.33%     
==========================================
  Files           5        6       +1     
  Lines         844      953     +109     
  Branches      108      126      +18     
==========================================
+ Hits          757      858     +101     
- Misses         52       58       +6     
- Partials       35       37       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@orbeckst , please review the OpenVDB.py file. After that, I will add some more test covering all the missing parts

fixed the CHANGELOG and OpenVDB.py. I didn't get the time to work on the blender part due to exams. I will surely try do it!

The first two are for naChR_M2_water.vdb and the last two are for 1jzv.vdb.
Also in the OpenVDB.py, the function should be transform.preTranslate which I will fix with the new tests.
Can you please confirm that these are the correct rendering?
I can provide the .vdb files as well here.

Good that you're able to load something into Blender. From a first glance I don;t recognize what I'd expect but this may be dependent on how you render in Blender. As I already said on Discord: Try to establish yourself what "correct" means. Load the original data in a program where you can reliably look at it. ChimeraX is probably the best for looking at densities; it can definitely read DX.

Btw, the M2 density should look similar to the blue "blobs" on the cover of https://sbcb.bioch.ox.ac.uk/users/oliver/download/Thesis/OB_thesis_2sided.pdf

The first one is for 1jzv.vdb and second for nAChR_M2_water.vdb (not done the shading/coloring)
I think the .vdb files as generated by the OpenVDB.py are now correctly rendering in blender.

Can I proceed with the tests part?

Mentioned in the Discord but also bringing up here: In your current examples (most obvious with the pore) is that the axis is flipped so that X is "up" compared to atomic coordinates which would have Z as up.

Mentioned in the Discord but also bringing up here: In your current examples (most obvious with the pore) is that the axis is flipped so that X is "up" compared to atomic coordinates which would have Z as up.

Thank you for the update! will try to fix this

I think this fixes the axis..

Ideally we would see this alongside the atoms or density from MN as well - to double check alignment because you might also need to flip one of the X or Y axes.

The scales might be different (larger or smaller by factors of 10) but you can just scale inside of Blender by that amount to align the scales, but we want to be double checking alignemnt and axes.

Hi @BradyAJohnston

I have first of all added the MolecularNode add-on as given in the https://github.com/BradyAJohnston/MolecularNodes, and imported the 1jzv.pdb. After that import the .vdb file and there was difference in size of two. So I made the size the .pdb bigger. The centers of both of them are same and I didn't flipped any of the axes in the ss provided.

I wrote a small blender py script to compare bounding boxes of the pdb and vdb objects to verify centroids, extents and axis alignment-

import bpy
from mathutils import Vector

def bbox_world(obj):
    bbox = [obj.matrix_world @ Vector(c) for c in obj.bound_box]
    mn = Vector((min(p[i] for p in bbox) for i in range(3)))
    mx = Vector((max(p[i] for p in bbox) for i in range(3)))
    return mn, mx

def centroid_world(obj):
    mn, mx = bbox_world(obj)
    return (mn + mx) / 2.0

def size_world(obj):
    mn, mx = bbox_world(obj)
    return mx - mn

pdb = bpy.data.objects.get("1jzv.001")
vdb = bpy.data.objects.get("1jzv")

print("pdb centroid:", centroid_world(pdb))
print("pdb size:", size_world(pdb))
print("vdb centroid:", centroid_world(vdb))
print("vdb size:", size_world(vdb))

output -
pdb centroid: <Vector (7.6985, 23.7885, 76.0560)>
pdb size: <Vector (33.1410, 45.4170, 29.3960)>
vdb centroid: <Vector (8.7238, 23.4452, 76.7628)>
vdb size: <Vector (43.6190, 52.3429, 40.3425)>

The centroids are almost same I guess...
the data seems to be correctly aligned

@spyke7 It's still not 100% clear from your screenshots - can you import with the pore instead as that is more clear? And when you are taking a screenshot it would be more helpful to have the imported density in the centre of the screen rather than mostly empty space.

Looks like you are attempting a standalone export to .vdb files from GridDataFormats. (If your end use case is to use this only within Blender, I'd strongly recommend using MolecularNodes to import various grid formats as it already uses GridDataFormats internally and provides a lot of cool features like varying ISO values, different colors for positive and negative ISO values, slicing along all three major axes, showing contours, centering, inverting etc - both from GUI and API) From a quick scan of the code, you seem to want to support both pyopenvdb (the older one) and openvdb (the newer one) - note that there are some minor differences to take into account between them. You can take a look at the grid_to_vdb method from an earlier version in MN that shows the differences and handles the export to .vdb within MolecularNodes. Hope this helps. Thanks

If this functionality can be added directly to GDF then we can also take advantage of that in MN going forwards.

If this functionality can be added directly to GDF then we can also take advantage of that in MN going forwards.

Agreed. In addition to exporting to .vdb format, we also add some additional metadata (currently, info about inversion, centered) that we later use. So as long as the metadata for Grids is carried over during export, we should probably be good. Thanks

In addition to exporting to .vdb format, we also add some additional metadata

This is a good point and something to consider as well. As far as I am aware Blender / MN (and other 3D animation packages) might be the only ones who use .vdb as a format rather than any scientific packages / pipelines.

If there is anything out there that does take .vdb then we might want to consider if any relevant metadata should be saved. We might want to standardise on relevant metadata entries (we could either re-use from MN or update inside of MN to more general ones) so that GDF interactions with .vdb attempt to approach some kind of standard. This might be a larger question outside of scope for a simple read / write, but certainly functionality to pass in custom metadata like we do in MN would be ideal.

The changes that I made test these implicitly so coverage is now sufficient but we should have explicit tests for key API functionality.

Yeah, I was looking into other comments, and will create the tests as required.
Once it is implemented, we can focus on solving #162

@PardhavMaradani I know that you're busy. Let us know if you would like to have some extra time for reviewing or if you're ok with proceeding as necessary.

This looks good to me. I am ok with proceeding as needed. A few minor points:

• For the metadata test (test_write_vdb_with_metadata), given name is already an existing attribute, it might be better to add some non-standard ones and verify (preferably using vdb.readAllGridMetadata)
• I believe the test test_write_vdb_origin_and_spacing is to check for the correctness of the transform.preScale and transform.postTransform transforms. Only the spacing (scale) is being verified. Maybe use something like transform.indexToWorld to verify the world space coords and check the translation too?
• The native vdb object access doesn't seem to be tested. With the changes in this PR, most of the MN code would get simplified and there would be only a couple of calls to get the native object (using convert_to) and create a new linear transform with the scale and translation that MN needs and use the GDF export method to write it out. So, it might be a good test to add too if possible

Thanks

@orbeckst pls check the test functions when you are free. I have added new tests for from_grid and native and covered the points given by @PardhavMaradani .

@PardhavMaradani I'd appreciate your final review of this PR if you have time.

Hi @orbeckst I think this can be merged now, then I can work on completing #162
Are there any other changes necessary?

Thank you for your major contribution @spyke7 ! Your big PR is merged! 🎉